iT邦幫忙

2024 iThome 鐵人賽

DAY 29
0
AI/ ML & Data

從點子構想到部署上線:機器學習專案的一生系列 第 29

[Day 29] Spotify 在建立機器學習專案學到的三件事

  • 分享至 

  • xImage
  •  

任何曾參與將機器學習模型投入 production 的人都知道,將模型從實驗階段推向 production 並非易事。身為 data-driven 的大公司 Spotify,在部署模型時也並非一帆風順。鐵人賽的倒數第二天,我們來看看 Spotify 他們在實作一整套 ML專案架構之後,學到什麼、發現什麼問題,是怎麼解決的吧!

線上預測中的錯誤

Spotify 在開發 Podcast 的推薦系統中,一開始是在離線做批次的模型訓練和預測。隨著推薦模型的演進,他們希望可以根據用戶的即時行為,如當前正在播放的節目、最近的操作記錄,快速生成個性化推薦。

不過,Spotify 在將模型部署到線上時,意外地使用到不正確的資料進行預測。這個錯誤的主因是在資料特徵的前處理,訓練和預測模型使用的是不同 pipelines,導致在線上預測時遺漏一些關鍵的數據處理步驟。更嚴重的是,他們當時沒有任何監控工具能夠偵測這個錯誤,竟然讓這個錯誤存在四個月之久。最後,系統不斷地提供跟用戶行為不符合的推薦內容,進而影響用戶的體驗。

我們曾在 Day 5 的 Step 2. 蒐集和準備資料 中提過,在實驗階段,就要確保這些資料處理的 pipeline 也可以複製到 production 環境,避免出現和 Spotify 一樣的錯誤。

經過這次事件,促使 Spotify 開始關注資料的驗證和控制,在資料不斷流動的線上預測情境中,如果無法確保線上服務使用的資料,與模型訓練時的資料具有相同的結構和品質,那麼推薦系統的預測結果將難以保持一致性和準確性。

另外,在實際的應用中,Spotify 也發現訓練數據與 production 數據之間的分佈差異可能會顯著影響模型的效能。Spotify 的推薦系統需要處理來自不同地區、文化背景的用戶資料,即便模型在訓練過程中達到了良好的表現,也確保線上的資料處理流程沒有問題。不過,一旦線上數據的分佈發生改變(例如,某些地區的用戶偏好改變),推薦結果的準確性也可能會大幅下降。

TensorFlow Data Validation (TFDV) 的引入

為此,Spotify 開始使用 TensorFlow Data Validation (TFDV),這是一個專門用於數據驗證的工具,監控和比較「訓練數據」與「線上數據」之間的結構和特徵分佈差異。TFDV 的主要功能是檢查數據是否符合預期,並在數據異常或分佈不一致時發出警報,幫助開發者及時發現和修正問題。

Spotify 利用 TFDV 每天比對訓練數據和線上數據的結構和特徵分佈,確保兩者保持一致。具體來說,TFDV 可以檢測到以下幾種常見的數據異常:

  • 特徵缺失:訓練數據中的某些特徵,在線上資料中可能缺失或未正確記錄,這會導致模型在線上預測時無法利用重要的特徵來生成推薦。
  • 特徵分佈變化:線上數據中,某些特徵的分佈可能與訓練數據顯著不同。這個變化可能是由於系統升級、資聊來源改變,或是其他外部因素所導致,進而影響模型的預測性能。
  • 數據型態不一致:某些特徵的數據型態可能在線上環境中產生變化,這會直接影響模型的預測結果。例如,一個數值型的特徵被錯誤地轉換為類別型數據,導致模型無法正確地使用此特徵。

Spotify 使用 TFDV 的自動化監控流程來檢測數據的特徵是否缺失以及分佈變化,並透過監控機制提醒資料科學家和開發者進行修正,確保模型在訓練和線上階段中使用的數據保持一致,從而提高推薦系統的準確性。

除了使用監控系統以外,他們在部署新的模型時,也都會先進行資料驗證,確保訓練和線上數據的一致性在可接受的範圍內。如果發現重大差異,系統將自動停止新模型的部署,避免使用不正確的數據進行預測。

儀表板工具

此外,Spotify 也開發了一個視覺化的儀表板工具,讓開發者可以自由地查看不同模型在不同用戶特徵下的推薦結果。這種可視化的評估方式能夠幫助他們發現一些自動化評估無法輕易觀察的問題。舉例來說,他們有一次發現,模型竟然為所有歐洲國家的用戶都推薦了同一張熱門播放清單,明顯忽視各國用戶的文化差異。透過儀表板的即時顯示,他們及時發現並修正了此問題,確保推薦系統能夠更好地滿足不同區域用戶的需求。


建立 baseline 模型以評估模型

Day 6 的 Step 3. 建立模型 中,我們曾經介紹過在訓練模型時,需要先建立一個 baseline 模型,用以評估模型的表現。

Spotify 也同樣使用這個方法來衡量模型表現。他們有一個名為 Shortcuts 的模型,會在首頁上推薦他們認為使用者接下來最想要聆聽的歌單。在開發此模型時,他們先設計一個初始的 baseline:根據用戶近期的播放歷史,將最常播放的項目推薦給用戶。這種設計跟比較,讓他們可以有效地評估新的模型是否帶來實質的進步。


模型重新訓練

最後,模型在訓練完成之後,也需要不斷地重新更新,避免出現 Day 8 Step 5. 監控模型表現 的模型老化(model staleness)問題。以 Podcast 模型為例,主要用來推薦節目給用戶。然而,Podcast 的節目內容會不斷地快速更新,但是模型只能夠推薦出現在訓練資料中的節目。因此,Spotify 勢必需要定期重新訓練模型,以確保新的節目能夠被推薦給用戶。如果不重新訓練,模型的推薦效果將會迅速衰退,無法跟上 Podcast 節目的更新速度。

在模型的部署初期,Spotify 是使用人工的方式進行重新訓練,因此花費了大量時間和資源。為了提高效率,Spotify 開始加強自動化的流程,他們透過 Kubeflow pipeline 來自動化模型的重新訓練和部署。在這個流程中,模型會根據預定的評估指標自動進行重新訓練,並根據訓練結果決定是否將新模型推送到線上環境。這樣的自動化流程不僅減少了人工干預的需求,還確保了模型的持續更新。


以上,我們用 Spotify 的一些經驗來整合前面介紹過的機器學習專案的內容,希望大家在實作自己的專案時,也可以學以致用!


謝謝讀到最後的你,如果喜歡這系列,別忘了按下喜歡和訂閱,才不會錯過最新更新。
如果有任何問題想跟我聊聊,或是想看我分享的其他內容,也歡迎到我的 Instagram(@data.scientist.min) 逛逛!
我們明天見!


Reference


上一篇
[Day 28] ML 專案的工具介紹 - Part 3. 實驗追蹤工具 - TensorBoard、Weights & Biases 和 MLflow
下一篇
[Day 30] 鐵人賽收工!心得 & 延伸閱讀分享
系列文
從點子構想到部署上線:機器學習專案的一生30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言